<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>



<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
<LINK rel="stylesheet" type="text/css" href="embroot.css">
<TITLE>
Remote Peer Queues
</TITLE>
</HEAD>
<BODY >
<A HREF="embroot055.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="embroot052.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="embroot057.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>

<H2 CLASS="section"><A NAME="htoc110">10.4</A>&nbsp;&nbsp;Remote Peer Queues</H2><UL>
<LI><A HREF="embroot056.html#toc59">Synchronous peer queues</A>
<LI><A HREF="embroot056.html#toc60">Asynchronous peer queues</A>
</UL>

As discussed in section&nbsp;<A HREF="embroot054.html#remoteprotobasic">10.2</A>, peer queues can be formed
interactively during an attachment between the two sides. The protocol
provides for the creation and closing of these queues on both sides. <BR>
<BR>
The handling of data on these queues are performed by <I>data handlers</I>,
routines which either provide data to the queue or consume data from the
queue. They are triggered by the appropriate control messages, so that a
data consumer handler would consume data arriving on a queue, and a data
provider handler would send data onto a queue (which would be consumed on
the other side). These data handlers can be user defined. <BR>
<BR>
The programmer for the remote side needs to provide the remote side of the
interface to the peer queue. <BR>
<BR>
<A NAME="toc59"></A>
<H3 CLASS="subsection"><A NAME="htoc111">10.4.1</A>&nbsp;&nbsp;Synchronous peer queues</H3>
The implementation of a synchronous peer queue on the ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> side is
shown in figure&nbsp;<A HREF="#syncpeer">10.2</A>. There is an in-memory buffer, which is
<BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<DIV CLASS="center">
<IMG SRC="embroot006.gif">
</DIV>
<BR>
<BR>
<DIV CLASS="center">Figure 10.2: ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> implementation of remote synchronous peer queue</DIV><BR>
<BR>

<A NAME="syncpeer"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></BLOCKQUOTE>
implemented as a memory queue in ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> (i.e. <TT>queue("")</TT> option
for <A HREF="../bips/kernel/iostream/open-3.html"><B>open/3</B></A><A NAME="@default331"></A>). Associated with the memory queue is the actual socket
stream to the remote side.
The memory queue is the queue that the user sees on the ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP>
side, with name <I>Name</I> and a unique integer id <I>Queue</I>, which is
the stream id for the memory queue. The id is used by both sides to identify
the queue, as it is unique (a symbolic name can always be reassigned), and
is used in the control messages. To conform to normal ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> streams,
these queues appear uni-directional to the user, i.e. data can be either
written to or read from the queue. The direction is <I>fromec</I> if the
direction of the data is from ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> to the remote side (i.e. 
ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> can output to the queue), and <I>toec</I>
if the direction is from the remote side to ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> (i.e. ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP>
can read from the queue). The user perform normal I/O operations on the
memory queue, and the protocol ensures that the data is transferred
correctly to the remote side without blocking.<BR>
<BR>
The socket stream is largely hidden from the user on the ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> side,
with data automatically transferred between it and the buffer. The buffer
is needed to ensure that when data is transferred between the two sides,
the I/O operation is synchronised (the data is being read on one end of the
socket while it is being written at the other), so no blocking will occur.
When a side needs to initiate an I/O operation with the other side (either
to write data to or read data from the other side via the socket stream), it must have control
(otherwise it would not be in a position to initiate an action). Before
performing the I/O operation, a control message is sent to the other side to
allow it to prepare to read the data before the I/O operation is actually
initiated. The memory queue thus serves to buffer the data before it is
transferred to the socket stream.<BR>
<BR>
The socket stream must be connected to the remote side before it could be
used. Control messages are used also to synchronise the connection of
the socket. The protocol does not specify if a buffer is needed on the
remote side, this depends on the facilities available in the language used
for the remote side.<BR>
<BR>
For a particular synchronous queue, a data handler can only be defined on
one side of the queue, but not both.<BR>
<BR>
<A NAME="toc60"></A>
<H3 CLASS="subsection"><A NAME="htoc112">10.4.2</A>&nbsp;&nbsp;Asynchronous peer queues</H3>
I/O operations on these queues do not need to be controlled by the remote
protocol, but their creation and closing is controlled by the remote
protocol, so that the remote interface can keep track of these queues.
These are implemented as raw socket streams on the ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP>
side, with I/O operations performed directly on the socket. The Name and
Queue id for the stream is thus those for the ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> socket stream. It
is the responsibility of the user to ensure that I/O operations do not
block on these queues. They are provided to allow asynchronous transfer of
data (e.g. from ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> side to the remote side without handing over
control), and also they allow more efficient transfer of data. <BR>
<BR>
<HR>
<A HREF="embroot055.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="embroot052.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="embroot057.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
